feat(desktop): share the Local Runtime Host - #3972

I re-reviewed the current exact head 6f57620a3f11f42f47e06a901bd52ceb7565e2d6. The recovery changes close the previous retry lock, but the PR is still not ready to approve because the owner-credential lifecycle remains incomplete.

Findings

P1 — Claimed connection codes accumulate durable full-owner credentials without a local revocation path.

Both initial setup and every later connection code create a fresh desktop-owner:<uuid> principal (apps/desktop/src/main/runtime-host-local-remote-access.ts:251 and :573). Credential finalization revokes existing active credentials only when their principal matches (packages/runtime-host/src/server/access-authority.ts:361-366), so these random principals never replace one another.

I exercised the current access-authority path by preparing and finalizing two codes. The durable access file retained two distinct active Remote Owner credentials, each bound to a different Client instance. These owners receive the complete REMOTE_OWNER_OPERATION_GRANTS, but Local Settings exposes only “New connection code”, “Turn off”, and “Remove background service” (runtime-host-profiles-section.tsx:391-405); it has no authorization list or per-client revoke action. Turning off Direct peer access or uninstalling the service also does not revoke credentials stored in the State Root.

Before merge, either make this one stable Local-share owner slot that can be replaced and revoked, or explicitly support multiple owners with understandable device labels, an authorization/status list, and individual revocation.

P2 — Connection-code failures are not actionable in English.

The import dialog sends every failure through settingsActionErrorMessage() (runtime-host-connection-code-dialog.tsx:52-61). For English, that helper does not classify the error and then returns unknownError even after safely redacting the original message (settings-error-copy.ts:31-35). A user therefore cannot distinguish malformed, expired, already-claimed, unreachable, or root-mismatch failures. Preserve typed failure reasons across the bridge and map them to safe, specific recovery guidance.

P2 — The UI does not explain the security and connectivity contract.

The current copy says only that the feature uses an experimental Direct peer and that the code is one-time. It should also state that there is no fallback transport, an unclaimed code expires after 15 minutes, the first claimant receives full Owner authority, and turning off Direct access or removing the service does not revoke an already claimed credential.

Verification

The new persisted handoff, peer-change, uninstall, and cleanup intents now recover through startup or the enabled recovery action, so the previous unavailable UI dead end is closed. Affected builds and 121 focused Desktop, CLI, and Runtime Host tests passed. All applicable hosted checks are successful; the conditional Eval job is skipped. The merge result against current main (45824cc78eaf0e02bbd07dbd6fd46adfd38bd985) is clean.

Posted by an automated review agent operated by @WAWQAQ. This is not an
independent human review and does not satisfy the committer review required by
CONTRIBUTING.md. A human is accountable for this comment — please push back if
anything here is wrong.

I re-reviewed the current exact head 491efd4ed4b71e6a09b09ce79bd773d04c38c032. The previous owner-lifecycle and connection-code UX findings are addressed, but one revocation race still makes this unsafe to approve.

P1 — “Revoke shared access” can report success while a newly claimed Owner remains active.

The Desktop implementation first lists credentials and selects the currently active credential, then revokes that credential by ID (apps/desktop/src/main/runtime-host-local-remote-access.ts:314-336). These are separate Host operations.

If an outstanding connection code is claimed between those operations, credential finalization removes the listed active credential and activates the new same-principal credential (packages/runtime-host/src/server/access-authority.ts:338-380). The later revoke of the stale ID returns { revoked: false } (access-authority.ts:300-305), but the Desktop ignores that result, clears its sharedAccess snapshot flag, and displays “Shared access revoked.” The newly claimed credential remains a durable Remote Owner with the full Owner grants.

I reproduced this with the current production access-authority implementation: after finalizing the pending successor and revoking the previously listed credential ID, the revoke result was false and the durable access file still contained the successor as active, bound to the new Client instance. The added Desktop test always mocks { revoked: true }, so it does not cover finalization racing between list and revoke.

Please make revocation a single Host-owned atomic revoke-by-principal operation. If that is not practical, the caller must at least inspect the revoke result and use bounded re-list/retry and postcondition verification until no matching active or pending credential remains; only then should the UI report success.

Posted by an automated review agent operated by @WAWQAQ. This is not an
independent human review and does not satisfy the committer review required by
CONTRIBUTING.md. A human is accountable for this comment — please push back if
anything here is wrong.

I re-reviewed the current exact head 7e3411b4694b01799b443f464ceeff85f39b090e. The previously reported owner-lifecycle, recovery, connection-code UX, security-copy, and revocation-race findings are closed, and I found no remaining P0–P2 issue.

The final change makes shared-access revocation one Host-owned principal operation serialized with pairing finalization. Both possible orderings leave the old and pending/new credentials unable to authenticate, persistence ambiguity still fails closed, the operation is unavailable to Remote Owners, and compatibility epoch 55 prevents mixed-version use. Focused Runtime Host and Desktop verification passed. The branch is directly based on current main, and its merge tree is clean.

The hosted test and quality jobs were still queued when I submitted this review. This approval covers the code review; merging should still wait for all required hosted checks to finish successfully on this exact head.

Posted by an automated review agent operated by @WAWQAQ. This is not an
independent human review and does not satisfy the committer review required by
CONTRIBUTING.md. A human is accountable for this comment — please push back if
anything here is wrong.